home *** CD-ROM | disk | FTP | other *** search
/ The Arsenal Files 8 / The Arsenal Files Collection #8 (Arsenal Computer) (1996).ISO / prg_casm / snpd9611.zip / DECOMPIL.TXT < prev    next >
Text File  |  1996-11-24  |  4KB  |  98 lines
  1. .I 0 1
  2. +++Date last modified: 18-Feb-1996
  3. .D 1 1
  4. .I 2 2
  5. Question:
  6.  
  7. .I 18 1
  8. decompiler designed to only work on code generated by, say, BC++ 4.52? This
  9. .D 19 1
  10. .I 44 81
  11. run into problems where the original source had files with multiple functions
  12. using static data and/or one or more functions calling one or more static
  13. functions. A decompiler could make static data and/or functions global but
  14. only at the expense or readability (which would already be unacceptable).
  15.  
  16.   Also, remember that commercial applications often code the most difficult
  17. or time-critical functions in assembler which could prove almost impossible
  18. to decompile into a C equivalent.
  19.  
  20.   Closely related to the issue of modularity is that of library code.
  21. Consider the ubiquitous "Hello world" program. After compilation it contains
  22. about 10 bytes of compiled source, about a dozen bytes of data, and anywhere
  23. from 5-10K (depending on compiler, target, memory model, etc.) of start up
  24. and library code. This is a great example since printf() also calls *lots* of
  25. other library functions of its own! Once the decompiler has assigned names to
  26. the dozen or so functions in its output, the fun starts when you have to
  27. figure out which arbitrarily-named function is really printf() and which
  28. other functions are library helper functions that it calls. The bottom line
  29. here is that in order to do so, you'd have to know enough about writing C
  30. libraries to be able to recognize the code for printf() when you see it.
  31.  
  32.   Again, the situation with C++ would be orders of magnitude more complex
  33. trying to make sense of the compiled code once the O-O structures and
  34. relationships had been compiled into oblivion. Even if you take the simple
  35. approach and decompile C++ into C, would anyone like to try and trace through
  36. the source to figure out a cout call which adds another 7-10K of overhead
  37. vis-a-vis a printf() call? I sure wouldn't!!!
  38.  
  39.   So what do your have? For a small program, you'd wind up trying to decipher
  40. what is mostly library source. For a large program, you'd wind up with either
  41. 1) one humonguous main(), or 2) lots of arbitrary single-function modules
  42. from which all notions of static data and functions would have been lost
  43. (contributing to a vast pool of global data), which would still include
  44. decompiled source for all the library objects as well. In any scenario, is
  45. any of this useful? Probably not.
  46.  
  47.   While we've touched on the topic of library code, here's yet another reason
  48. that C and C++ are particularly difficult to de-compile: macros.
  49.  
  50. For instance, if I have something like:
  51.  
  52.     while (EOF != ( ch = getchar())) {
  53.         if (isupper(ch))
  54.             putchar(ch);
  55.  
  56. getchar, EOF, putchar and isupper are all typically macros, something like:
  57.  
  58. #define EOF -1
  59. #define isupper(x) (__types[(unsigned char)x+1] && __UPPER)
  60. #define getchar()  (getc(stdin))
  61. #define putchar(c) (putc((c),stdout)
  62.  
  63. #define getc(s) ((s)->__pos<(s)->__len?     \
  64.     (s)->__buf[__pos++]:                    \
  65.       filbuf(s))
  66. #define putc(c,s) ((s)->__pos<(s)->__len?   \
  67.     (s)->__buf[__pos++]=(c):                \
  68.     putbuf((s),(c)))
  69.  
  70. Finally, stdin and stdout are generally just items in an array of FILE
  71. pointers something like:
  72.  
  73. FILE __iobuf[20];
  74.  
  75. FILE *stdin = __iobuf;      // This part is done silently by the
  76. FILE *stdout = __iobuf + 1; // compiler, without actual source code
  77. FILE *stderr = __iobuf + 2;
  78.  
  79.  
  80. Even if you just expand the macros and never actually compile the code at
  81. all, you end up with something that's basically unreadable. However, this is
  82. what actually gets fed to the compiler, so it's also absolute best you could
  83. ever hope for from a perfect de-compiler.
  84.  
  85. C++ of course adds in-line functions and after an optimizer runs across
  86. things, the code from the in-line function may well be mixed in with
  87. surrounding code, making it nearly impossible to extract the function from
  88. the code that calls it.  There are only a few formats in use for vtables,
  89. which would help in preserving virtual functions, but inline functions would
  90. be lost, so you'd typically end up with hundreds of times that code would be
  91. directly accessing variables in other classes.
  92. .D 45 8
  93. .I 63 4
  94.  
  95.   A general purpose decompiler is the Holy Grail of tyro programmers. 
  96.  
  97. [by Bob Stout & Jerry Coffin]
  98.